SPIKE: Protocol 28 (CAP-0084)#307
Conversation
Add SC_ADDRESS_TYPE_MUXED_CONTRACT arm and MuxedContract struct to SCAddress, gated behind #ifdef CAP_0084_MUXED_CONTRACT, mirroring the existing MuxedEd25519Account muxed-account pattern. Appears only in the `next` branch until core bumps the max supported protocol to 28. CAP-0084 (Muxed Contract Addresses): stellar/stellar-protocol#1968
There was a problem hiding this comment.
Pull request overview
This PR spikes Protocol 28 / CAP-0084 support by introducing a feature-gated “muxed contract” SCAddress variant, mirroring the existing muxed-account pattern, and includes a deliberate comment revert in the ledger XDR.
Changes:
- Add
SC_ADDRESS_TYPE_MUXED_CONTRACTplusMuxedContract { id, contractId }and a newSCAddressunion arm behind#ifdef CAP_0084_MUXED_CONTRACT. - Revert a
Stellar-ledger.xdocumentation comment related torentFeeCharged.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| Stellar-contract.x | Adds a feature-gated muxed-contract address type and corresponding struct/union arm. |
| Stellar-ledger.x | Reverts a rent-fee documentation comment inside SorobanTransactionMetaExtV1. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
rentFeeCharged is part of totalRefundableResourceFeeCharged (as the totalRefundableResourceFeeCharged comment itself states: 'comprises the rent fee'). An automation drive-by had flipped it to NonRefundable — out of scope for CAP-0084 and factually wrong. Restores the original comment; stellar#307 now touches only Stellar-contract.x (the CAP-0084 XDR).
| uint256 ed25519; | ||
| }; | ||
|
|
||
| #ifdef CAP_0084_MUXED_CONTRACT |
There was a problem hiding this comment.
Is the additional suffix necessary? I'm not sure if it adds much value, given that we shouldn't have more than a single guard per CAP.
There was a problem hiding this comment.
This was based on some feedback in the FSR channel. It just adds a little clarity so you don't need to remember what the CAP number does.
There was a problem hiding this comment.
Ok, I don't have too strong opinion, we can try this as well.
Changes
SC_ADDRESS_TYPE_MUXED_CONTRACTenum arm +MuxedContract { uint64 id; ContractID contractId; }struct +SCAddressunion arm toStellar-contract.x, all gated behind#ifdef CAP_0084_MUXED_CONTRACT, mirroring the existingMuxedEd25519Accountmuxed-account pattern.nextbranch (built--all-features) and stay out ofcurruntil core bumps max protocol to 28.curr/nextregenerate automatically on merge — not edited here.Stellar-ledger.xcomment revert (deliberate — reviewer please note): drops the unrelated Fix conflicting comment on rent fee #304 comment change so the p28 SPIKE XDR base stays byte-identical to the frozen p27 host (ledger.xhash93cdd4dd), avoiding downstream host-identity drift.Flag-token contract (downstream)
This repo is the root of the chain — no upstream. Downstreams pin this PR's head commit by full 40-char SHA:
787382ef2099cca168ca1cb282730d6b7b9e2f16(never the truncated787382e). The ifdef tokenCAP_0084_MUXED_CONTRACTis the verbatim contract for every downstream:cap_0084_muxed_contractXDR_FEATURES/xfile preprocess --features(go-stellar-sdk / js-stellar-base):CAP_0084_MUXED_CONTRACTA mismatched/truncated token silently strips the new types downstream.
Verification
Local
stellar-xdr xfile preprocess: arm absent with no features (curr); all three arms present and file parses with--features CAP_0084_MUXED_CONTRACT.Deferred
Downstream: stellar/rs-stellar-xdr#551 (pins this PR head
787382e)CAP-0084: stellar/stellar-protocol#1968